In-service software upgrade utilizing metadata-driven state translation

ABSTRACT

A method and apparatus for a metadata-driven upgrade of a network element is described. A network element comprises an active and backup controller card and receives new software to be installed on that network element. In addition, the network element installs the software on the backup controller card and synchronizes the active state of the network element to the backup controller card. Furthermore, the network element uses metadata to translate the active state to the format used by the new software.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 12/009,563,filed Jan. 18, 2008, which claims the benefit of U.S. ProvisionalApplication No. 60/995,882, filed Sep. 27, 2007, which are herebyincorporated by reference.

BACKGROUND

1. Field

Embodiments of the invention relate to the field of computer networking;and more specifically, to upgrading network elements utilizing metadatastate translation.

2. Background

A network element in a service provider's network typically handles highvolumes of data traffic (“traffic”) from users accessing severaldifferent services and/or communicating with other users. For example, anetwork element can handle services for up to tens of thousands ofusers. An interruption in the operation of the network element can causea disruption of service to these tens of thousands of users.

FIG. 1 illustrates one embodiment of a service provider network 100 witha network element forwarding traffic between end stations and contentservers through a network. While in one embodiment, network element is arouter, in alternate embodiment, network element can be other networkingequipment known in the art (switch, hub, firewall, server, etc.).Furthermore, while in one embodiment network element forwards traffic,in alternate embodiment, network element can perform the same and/ordifferent traffic processing (switch traffic, shape traffic, applyaccess controls, apply firewall policies, provide file storage ordatabase access, serve web pages, etc.) In FIG. 1, network 100 comprisesend stations 102A-C, network element 104, core network 106, and contentservers 108A-B. End stations 102A-C couple to network element 104 andnetwork element couples to content servers 108A-B through core network106. While in one embodiment, end station 102A-C are home personalcomputers, in alternate embodiments, end stations can be the same ordifferent type of machine (e.g., business computer, personal digitalassistant, cell phone, game console, handheld game system, laptopcomputer, etc.). End stations can couple to network element through anyone of the means know in the art (e.g., Ethernet, wireless, digitalsubscriber line (DSL), cable modem, fiber, etc.). Network element 104provides an entry point into core network 106 by forwarding traffic fromend stations 102A-C to content servers 108A-B, from content servers108A-B to end stations 102A-C, and traffic going between end stations102A-C. While in one embodiment, network element 104 is an edge networkelement that forwards traffic between the edge network servicing endstations 102A-C and core network 106, in alternate embodiments, networkelement 104 can be a network element or switch positioned differently inthe service provider's edge and/or core networks.

Core network 106 is the backbone network of the service provider thattypically has high capacity to handle that high volume of traffictraveling through network 100. Content servers 108A-B serve contentand/or control information for services offered to end stations 102A-C.

As network element 104 handles the traffic for this large number ofusers, network element 104 accumulates state information that controlsthe handling of the traffic. While in one embodiment the stateinformation accumulated by network element 104 is a traffic forwardingtable, in alternate embodiments, the state accumulated has the sameand/or different information (configuration data, user sessioninformation, firewall information, access control lists, quality ofservice information, statistics, etc.). This state is typically run-timeinformation that does not survive a reboot of network element 104.

Periodically, a network element receives a software upgrade to itsservices. Typically, a software upgrade requires a reboot of the networkelement so that software upgrade can take effect. However, a rebootdisrupts the service and wipes out the built up state, because the statedoes not survive a reboot. Even though a reboot of a network element canoccur quickly, the rebuilding of the state typically takes longer.Rebuilding of the state involves reconnecting subscribers, rebuildingforwarding tables, subscriber session information, etc.

An improved software upgrade method, termed an “in-service” upgrade, isused when the network element has one or more redundant peers. A peercould be another instance of the same type of network element occupyingan equivalent position in the network topology or a redundant componentof the network element itself. For example, a network element, such asnetwork element 104, that has two or more controller cards can utilizean in-service upgrade. An in-service upgrade involves first installingand initializing the new software on a backup or standby controller,synchronizing the network element state to the backup controller,switching control to the backup controller and then driving the softwareupgrade and state restoration to the other network element components.In this algorithm, the backup controller becomes the active controllerfor the network element and the former active controller is the backupcontroller.

FIG. 2 is a block diagram of a network element 200 that includesredundant controller cards. In FIG. 2, backplane 206 couples to linecards 202A-N and controller cards 204A-B. While in one embodiment,controller cards 204A-B control the processing of the traffic by linecards 202A-N, in alternate embodiments, controller cards 204A-B performthe same and/or different functions (upgrade software, handle operatorrequests, collect statistics, etc.) Line cards 202A-N process andforward traffic according to the policies received from controller cards204A-B. In an alternative embodiment, network element 200 can have onecontroller card or more than two controller cards.

FIG. 3 is a block diagram of an active controller card passing activestate information to a backup controller card. An active controller cardis the card that controls the functions of a network element. The backupcontroller card is the card that is a standby card that could take overcontrol of the network element. For example and by way of illustration,the backup controller card would take over controlling the networkelement in cases of active controller card failure, upgrade of thenetwork element, etc. While in one embodiment, active state informationis the state accumulated by network element 104 as described inreference with FIG. 1, in alternate embodiment, active state informationis the same and/or different information used to control network element104. In FIG. 3, active controller card 302A sends active stateinformation 304 to backup controller card 302B. The in-service upgradealgorithm uses the active state information to perform the upgrade ofthe network element without a disruption of traffic processing.

A drawback of the in-service upgrade is that the upgrade needs toaccount for the differences between the old and the new software in theexpected format and semantic content of the state. The in-serviceupgrade algorithm requires that the new software contain explicitknowledge of the precise format and the content of the state datasynchronized from the controller running the older software or that thestate data be transported in a version-independent format such astag-length-value. However, the values conveyed by a version-independentformat are not defined in any fashion that supports the translationprocess. There would still need to be knowledge embedded in the softwareimages about the relationship between the version-dependent internalformat and the version-independent external format. Using theversion-independent format for communication requires the activecontroller to convert the state data from the native form to anintermediate version-independent format form, send theversion-independent format to the backup controller, then convert theversion-independent format back to the native form. Encoding suchknowledge in the software through writing special-purpose softwareroutines is time-consuming and prone to error.

BRIEF SUMMARY

A method and apparatus for a metadata-driven upgrade of a networkelement is described. A network element comprises an active and backupcontroller card and receives new software to be installed on thatnetwork element. In addition, the network element installs the softwareon the backup controller card and synchronizes the active state of thenetwork element to the backup controller card. Furthermore, the networkelement uses metadata to translate the active state to the format usedby the new software.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention may be best understood by referring to thefollowing description and accompanying drawings which illustrate suchembodiments. The numbering scheme for the Figures included herein issuch that the leading number for a given element in a Figure isassociated with the number of the Figure. However, element numbers arethe same for those elements that are the same across different Figures.In the drawings:

FIG. 1 (Prior Art) illustrates one embodiment of network elementhandling traffic between end stations content servers through a network.

FIG. 2 (Prior Art) is a block diagram of a network element withredundant controller cards.

FIG. 3 (Prior Art) is a block diagram of an active controller cardpassing active state information to a backup controller card.

FIG. 4 is a block diagram illustrating metadata creation at the time thesoftware is constructed and the role that metadata serves at the time anindividual network element's software is upgraded according to oneembodiment of the system.

FIG. 5 is an exemplary flow diagram for performing an in-service upgradeusing metadata state translation according to one embodiment of thesystem.

FIG. 6 is an exemplary flow diagram for creating the metadata accordingto one embodiment of the system.

FIG. 7 is a block diagram illustrating a controller card according toone embodiment of the invention.

DETAILED DESCRIPTION

In the following description, numerous specific details such as networkelement, metadata, metadata format, data definition language, activestate information, packet, processor card, line card, controller card,and interrelationships of system components are set forth in order toprovide a more thorough understanding of the invention. It will beappreciated, however, by one skilled in the art that the invention maybe practiced without such specific details. In other instances, controlstructures and full software instruction sequences have not been shownin detail in order not to obscure the invention. Those of ordinary skillin the art, with the included descriptions, will be able to implementappropriate functionality without undue experimentation.

References in the specification to “one embodiment”, “an embodiment”,“an example embodiment”, etc., indicate that the embodiment describedmay include a particular feature, structure, or characteristic, butevery embodiment may not necessarily include the particular feature,structure, or characteristic. Moreover, such phrases are not necessarilyreferring to the same embodiment. Further, when a particular feature,structure, or characteristic is described in connection with anembodiment, it is submitted that it is within the knowledge of oneskilled in the art to affect such feature, structure, or characteristicin connection with other embodiments whether or not explicitlydescribed.

In the following description and claims, the term “coupled,” along withits derivatives, is used. “Coupled” may mean that two or more elementsare in direct physical or electrical contact. However, “coupled” mayalso mean that two or more elements are not in direct contact with eachother, but yet still co-operate or interact with each other. Exemplaryembodiments of the invention will now be described with reference toFIGS. 4-7. In particular, the operations of the flow diagrams in FIGS. 5and 6 will be described with reference to the exemplary embodiments ofFIGS. 4 and 7. However, it should be understood that the operations ofthese flow diagrams can be performed by embodiments of the inventionother than those discussed with reference to FIGS. 4 and 7 and that theembodiments discussed with reference to FIGS. 4 and 7 can performoperations different than those discussed with reference to these flowdiagrams.

A method and apparatus for upgrading a network element using metadata isdescribed. According to one embodiment of the invention, the networkelement uses metadata that describes the fields and structures of theactive state maintained by the network element. The active state isinformation maintained by the network element and derived fromcommunications and interactions with other elements on the network.Furthermore, the active state is information that does not survive areboot of the network element. The network element translates thecurrent active state using the metadata to a format that supports newsoftware associated with the upgrade.

FIG. 4 is a block diagram illustrating network element software upgradesystem according to one embodiment of the system. While in oneembodiment, the software is a new or upgraded network element operatingsystem, in alternate embodiments, the software is one or more new and/orupgraded services used by the network element. In FIG. 4, activecontroller card 418A sends active state information 416 to backupcontroller card 418B. In one embodiment, active controller card 418A andbackup control 418B card run different versions of software. While inone embodiment, the software running on backup controller card 418B isan upgraded version of software running on the active controller card418A, in alternative embodiments, the software versions running oncontroller cards 418A-B can be the same and/or different software. Asdescribed in FIG. 1, active state information 416 can comprise dynamicstate built up during runtime. In one embodiment, active stateinformation is the state built up as described above. Backup controllercard 418B comprises translation module 414 that translates active stateinformation 416 from the software running on active controller card 418Ato a form for use with the upgraded software running on backupcontroller card 418B. While in one embodiment, translation module 414uses metadata 404 for the active state information 416 translation, inalternate embodiments, translation modules used the same and/ordifferent information for the active state translation (e.g. metadataassociated with the old software, etc.).

In addition, in FIG. 4, metadata 404 is generated from data definitionlanguage (DDL) data 402. While in one embodiment metadata 404 is definedin extensible markup language (XML), in alternative embodiments,metadata 404 is defined in alternative format (plain text, HypertextMarkup Language (HTML), word processing formats known in the art,database formats known in the art, a proprietary format, etc.).Furthermore, in one embodiment, metadata 404 is extensible and versionindependent. In one embodiment, metadata 404 describes the structure andfields of active state information 416. In this embodiment, metadata 404describes the constituent fields of each active state information 416data structure, including the name, type, size, and offset in that datastructure. While in one embodiment, metadata 404 supports data typessuch as strings, integers, real numbers, Booleans, in alternativeembodiments, metadata 404 supports the same and/or other data types(enumerations, constants, bitmasks, type definitions, etc.).Furthermore, data structures can be defined in metadata 404 using suchdata types. In one embodiment, metadata 404 and/or source code headers406 is generated using a DDL parser known in the art (not shown).

While in one embodiment, the DDL resembles the programming language C'sdata definitions with additional fields and features for defininginformation useful for data conversion and translation, in alternateembodiments, the DDL can be another language that supports defining datatypes and structures (another programming language, XML, plain text,etc.).

In one embodiment, DDL data 402 contains data that describes thestructure and fields of active state information 416 in the DDL format.In one embodiment, DDL data is processed into source code headers 406.While in one embodiment source code headers 406 are C language headers,in alternative embodiments, source code headers 406 can be in adifferent language header (C++, Pascal, etc.). In one embodiment,compiler 410 compiles source code 408 and source code headers 406 intonetwork element operating system 412. While in one embodiment, software412 is the network element operating system that runs the networkelement, including the software that controls the traffic forwarding,processing, shaping, etc. functions of the network element, in anotherembodiment, software 412 is one or more services used by the networkelement. As described above, software 412 is sent to backup controllercard 418B to upgrade the network element.

FIG. 5 is an exemplary flow diagram of a method 500 for performing anin-service upgrade using metadata state translation according to oneembodiment of the system. In FIG. 5, at block 502, method 500 receivesthe new software. In one embodiment, the network element receives thenew software.

At block 504, method 500 installs the software on the active controllercard. In one embodiment, the new software are transferred over a networkand written to non-volatile storage medium, such as flash memory or adisk drive. Method 500 installs the software on the backup controllercard at block 506. In one embodiment, method 500 reboots the backupcontroller so the new software is running on the backup controller.

At block 508, method 500 receives the old software metadata from theactive controller card. In one embodiment, the received metadata is thestructure and fields of active state information 416 associated with theold software and are generated from DDL data 402 as discussed inreference to FIG. 4 above.

At block 510, method 500 synchronizes the backup controller active stateinformation to the active controller active state information. In oneembodiment, method 500 sends active state information 416 from theactive controller card 418A to backup controller card 418B as describedin reference to FIG. 4 above.

At block 512, method 500 automatically translates the active stateassociated with the old software to the new active state associated withthe new software using the metadata. In one embodiment, method 500compares the metadata associated with the new software to the receivedmetadata associated with the old software to identify the differencesbetween the two sets of metadata. With these differences, method 500recognizes field changes that are compatible for the automatictranslation. Method 500 propagates data elements corresponding to knownfields from the current active state to the new active state. Forexample and by way of illustration, method 500 translates an old activestate data structure A containing one unsigned int field to a new activestate data structure A containing a sixteen character string field andthe same unsigned int field by offsetting the unsigned int field theappropriate number of bytes to store the new character string field.Method 500 handles fields that are in a data structure of the newmetadata by adding, removing, or rearranging fields within the datastructure using general purpose, metadata-driven translation routines.In addition, method 500 can assign a default value to a field, increaseor decrease the size of a field, change a literal definition associatedwith an enumerated constant, split a field into sub-fields, change thenumber of elements in a vector, change certain datatypes with othercompatible datatypes (such as a signed integer to an unsigned integer),shift the location of bits in bitfields, change the location of a fieldwithin a structure, etc. This reduces the amount of specific translationroutines, such as the type used in block 514 below.

At block 514, method 500 optionally manually translates parts of the oldactive state information that were not translated automatically in block512. In one embodiment, method 500 uses the old metadata as an input todetermine and execute any additional steps needed to translate the olddata structure to the new data structure.

At block 516, method 500 synchronizes checkpoints of the changing activestate during the translation. In one embodiment, method 500 monitors thetranslation process via a checkpoint mechanism. In this embodiment, eachcomponent of method 500 that translates data, reports when the data hasbeen successfully translated. In one embodiment, method 500 waits untileach component reports that the data has successfully transferred andtranslated.

At block 518, method 500 switches control of the network element fromthe active controller card to the backup controller card. In thisembodiment, the backup controller card becomes the active card and theformer active controller card is the backup. In this embodiment, method500 reboots the former active controller card, so that the former activecontroller card is running the new software. In addition, method 500synchronizes the state between the new active controller card and thenew backup controller card. For example and by way of illustration,method 500 switches over control from controller card 418A to controllercard 418B (as described in reference with FIG. 4). Method 500 rebootscontroller card 418A so that controller card 418A is running the newsoftware. Moreover, method 500 synchronizes the active state incontroller card 418B to controller card 418A.

At block 520, method 500 upgrades the software running on othercomponents in the system. In one embodiment, method 500 uses the newsoftware to upgrade the packet processor(s) on each line card. Method500 resets the packet processors so the packet processors are using thenew software associated with the packet processors.

FIG. 6 is an exemplary flow diagram of a method 600 for creating themetadata according to one embodiment of the system. In FIG. 6, at block602, method 600 defines the active state data in the DDL. In oneembodiment, method 600 defines the format of the active state asdiscussed in FIG. 4 at block 402 above. At block 604, method 600 createsthe metadata from the state data definitions. In one embodiment, method600 creates metadata by parsing the state data format definitions in theDDL as described further with reference to FIG. 4.

At block 606, method 600 creates the programming language data typedefinitions for the defined state data format. In one embodiment, method600 creates the data type definitions as described in FIG. 4. At block608, method 600 compiles the new software from the data type definitionsand the other software source code. In one embodiment, method 600compiles the new software from the generated data type definitions andother software code as described in reference with FIG. 4.

FIG. 7 is a block diagram illustrating a controller card 702 accordingto one embodiment of the invention. In FIG. 7, controller card 702comprises control module 704, upgrade module 706, state receiving module708, state translating module 710, state synchronization module 712,synchronization checkpoint module 714, software management module 716,and line card upgrade module 718. While in one embodiment, controllercard 702 is controller cards 418A-B, in alternate embodiments,controller card is one of controller card 418A-B. Control module 704performs control of controller card 702 and switches control of thecontroller cards as described in FIG. 5, block 518. Upgrade module 706controls the network element software upgrade process of controller card702. State metadata receiving module 708 receives the old metadata asdescribed in FIG. 5, block 508. State translating module 710 translatesthe received active state to support the new software as described inFIG. 5, block 512. In one embodiment, state translating module 710 istranslation module 420. State synchronization module 712 synchronizesthe active information between the active controller card and the backupcontroller card as described in FIG. 5, block 510. Checkpointsynchronization module 714 maintains and monitors the checkpoints duringthe active state translation as described in FIG. 5, block 516. Softwaremanagement module 716 receives and stores the new software and metadatafor a controller card as described in FIG. 5, blocks 502, 504 and 506.Line card upgrade module 718 upgrades the line card as described in theFIG. 5, block 520.

This implementation of the metadata driven upgrade is an example, andnot by way of limitation. Thus, network elements having otherarchitectural configurations can incorporate embodiments of theinvention. Examples of other network elements that could incorporateembodiments of the invention could have multiple controller cards orhave a single controller card incorporating the functionality ofmetadata driven in-service upgrade.

Controller cards 204A-B as well as line cards 202A-N included in thedifferent network elements include memories, processors and/orApplication Specific Integrated Circuits (ASICs). Such memory includes amachine-readable medium on which is stored a set of instructions (i.e.,software) embodying any one, or all, of the methodologies describedherein. Software can reside, completely or at least partially, withinthis memory and/or within the processor and/or ASICs. For the purposesof this specification, the term “machine-readable medium” shall be takento include any mechanism that provides (e.g., stores) information in aform readable by a machine (e.g., a computer). For example, amachine-readable medium includes read only memory (ROM); random accessmemory (RAM); magnetic disk storage media; optical storage media; flashmemory devices; etc.

Alternative Embodiments

While the invention has been described in reference to an active andbackup controller card, in alternate embodiments, two network elementscould be used for a metadata driven translation of an active state of anactive network element. In this embodiment, the second network elementwould synchronize the active state, translate the active state using themetadata to support new software and switch control to the secondnetwork element. Further in this embodiment, the second network elementwould be the active network element and the first network element wouldbecome the backup for the second network element.

For example, while the flow diagrams in the figures show a particularorder of operations performed by certain embodiments of the invention,it should be understood that such order is exemplary (e.g., alternativeembodiments may perform the operations in a different order, combinecertain operations, overlap certain operations, etc.).

While the invention has been described in terms of several embodiments,those skilled in the art will recognize that the invention is notlimited to the embodiments described, can be practiced with modificationand alteration within the spirit and scope of the appended claims. Thedescription is thus to be regarded as illustrative instead of limiting.

What is claimed is:
 1. A method performed within a network elementhaving a first controller card and a second controller card, the methodcomprising: receiving new software to be installed on the networkelement, wherein the first controller card is currently acting as anactive controller card and is running old software that uses a firstdata structure format, wherein the new software comprises secondmetadata describing a second data structure format used by the newsoftware, wherein the first data structure format is not the same as thesecond data structure format; installing the new software on the secondcontroller card, wherein the second controller card is currently actingas a backup controller card; synchronizing, from the first controllercard onto the second controller card, active state data representing anactive state of the network element, wherein the active state data isstored in the first data structure format; and translating the activestate data synchronized onto the second controller card from the firstdata structure format into the second data structure format using thesecond metadata, wherein the active state data that is translated usingthe second metadata includes at least one of a traffic forwarding table,user session information, and subscriber session information, whereinthe active state data that is translated has been dynamically built upduring runtime and is used to control how the network element handlesdata traffic.
 2. The method of claim 1, wherein the new software is oneof a network element operating system and a service running on thenetwork element.
 3. The method of claim 1, wherein a first metadatadescribes constituent fields of the first data structure format used bythe old software including names, types, and sizes of the constituentfields, and wherein translating comprises comparing the second metadatadescribing the second data structure format used by the new softwarewith the first metadata associated with the old software.
 4. The methodof claim 1, further comprising switching control from the firstcontroller card over to the second controller card so that the secondcontroller card begins to act as the active controller card, wherein thesecond controller card is running the new software.
 5. The method ofclaim 1, wherein the translating also includes one or more of adding afield to the first data structure format, removing a field from thefirst data structure format, rearranging two or more fields in the firstdata structure format, and changing a literal value associated with anenumerated constant.
 6. The method of claim 1, further comprisingassigning a default value to a field of the second data structureformat, wherein there is no corresponding field in the first datastructure format.
 7. A machine-readable storage medium that storesinstructions, which when executed by a set of one or more processors,causes said set of one or more processors to: responsive to receivingnew software, install the new software on a second controller card,which is currently acting as a backup controller card, while a firstcontroller card, which is currently acting as an active controller card,runs old software that uses a first data structure format, wherein thenew software comprises second metadata that describes a second datastructure format used by the new software, wherein the first datastructure format is not the same as the second data structure format;synchronize active state data that represents an active state of anetwork element, from the first controller card onto the secondcontroller card , wherein the active state data is stored in the firstdata structure format; and translate the active state data synchronizedonto the second controller card from the first data structure formatinto the second data structure format using the second metadata, whereinthe active state data to be translated using the second metadataincludes at least one of a traffic forwarding table, user sessioninformation, and subscriber session information, wherein the activestate data to be translated is dynamically built up during runtime andis used to control how the network element handles data traffic.
 8. Themachine-readable storage medium of claim 7, wherein the new software isone of a network element operating system and a service that runs on thenetwork element.
 9. The machine-readable storage medium of claim 7,wherein a first metadata describes constituent fields of the first datastructure format used by the old software including names, types, andsizes of the constituent fields, and wherein the translation of theactive state comprises a comparison of the second metadata thatdescribes the second data structure format used by the new software withthe first metadata associated with the old software.
 10. Themachine-readable storage medium of claim 7, wherein the instructionsfurther cause the set of one or more processors to: switch control fromthe first controller card over to the second controller card so that thesecond controller card begins to act as the active controller card,wherein the second controller card runs the new software.
 11. Themachine-readable storage medium of claim 7, wherein the translation ofthe active state includes an operation to change the byte offset of afield within the second data structure format from the byte offset ofthe corresponding field within the first data structure format.
 12. Themachine-readable storage medium of claim 7, wherein the translation ofthe active state also includes one or more of addition of a field to thefirst data structure format, removal of a field from the first datastructure format, rearrangement of two or more fields in the first datastructure format, and change of a literal value associated with anenumerated constant.
 13. The machine-readable storage medium of claim 7,wherein the instructions further cause the set of one or more processorsto: assign a default value to a field of the second data structureformat, wherein there is no corresponding field in the first datastructure format.
 14. A network element comprising: a first controllercard and a second controller card; a machine-readable storage mediumstoring instructions, which when executed by a processor of the networkelement, cause said network element to: responsive to receiving newsoftware, install the new software on the second controller card, whichis currently acting as a backup controller card, while the firstcontroller card, which is currently acting as an active controller card,runs old software that uses a first data structure format, wherein thenew software comprises second metadata that describes a second datastructure format used by the new software, wherein the first datastructure format is not the same as the second data structure format;synchronize, from the first controller card onto the second controllercard, active state data that represents an active state of the networkelement, wherein the active state data is stored in the first datastructure format; and translate the active state data synchronized ontothe second controller card from the first data structure format into thesecond data structure format using the second metadata, wherein theactive state data that is translated using the second metadata includesat least one of a traffic forwarding table, user session information,and subscriber session information, wherein the active state data thatis translated has been dynamically built up during runtime and is usedto control how the network element handles data traffic.
 15. The networkelement of claim 14, wherein a first metadata describes constituentfields of the first data structure format used by the old softwareincluding names, types, and sizes of the constituent fields, and whereinthe translation of the active state comprises a comparison of the secondmetadata that describes the second data structure format used by the newsoftware with the first metadata associated with the old software. 16.The network element of claim 14, wherein the network element isoperative to switch control from the first controller card over to thesecond controller card so that the second controller card begins to actas the active controller card, wherein the second controller card runsthe new software.
 17. The network element of claim 14, wherein the newsoftware is one of a network element operating system and a service thatruns on the network element, and wherein the active state that is to betranslated includes a traffic forwarding table.
 18. The network elementof claim 14, wherein the translation of the active state includes anoperation to change the byte offset of a field within the second datastructure format from the byte offset of the corresponding field withinthe first data structure format.
 19. The network element of claim 14,wherein the translation of the active state also includes one or more ofaddition of a field to the first data structure format, removal of afield from the first data structure format, rearrangement of two or morefields in the first data structure format, and change of a literal valueassociated with an enumerated constant.
 20. The network element of claim14, wherein the instructions further cause the network element to:assign a default value to a field of the second data structure format,wherein there is no corresponding field in the first data structureformat.